Review: per-invocation attribution for egress-proxy + MCP consent (#341, #366)

Clean, well-reasoned PR. Concurrency is correct, leak-prevention is sound, and the MCP attribution stays strictly on the observability side of the security boundary — no cross-user misattribution. No blocking or security findings. Merge-ready. CI fully green.

SequenceRegistry — race- and leak-safe ✅

• Concurrency: map is mutex-guarded; NextSequenceFor does Add(1) on the live *atomic counter, so out-of-band and in-context emitters advance the same counter — no lost increments or duplicate seqs. Eviction racing an in-flight Add is safe (the counter object outlives the map entry via the returned pointer; no panic, no race — the -race suite backs this).
• Leak-safe: defer r.registerInvocationSeq(ctx)() registers immediately, evicts on return including panic unwinding. Nil/empty-key guards prevent phantom entries.
• Correct sentinel: real seqs start at 1 (Add(1) on zero), miss returns 0 → JSON-omitted, so "unregistered" and a real seq never collide.
• Key safety: corr + "\x00" + task rules out the ("a","bc") vs ("ab","c") ambiguity.

#341 wiring — the key match holds ✅

Verified the thing that would silently defeat this: at all three A2A entry points (JSON-RPC, executeTask, REST), EnsureCorrelationID + WithTaskID + EnsureSequenceCounter run before registerInvocationSeq, so the registration key is the real (corr, task) the subprocess later replays via Proxy-Authorization (#338). The proxy's NextSequenceFor hits the right counter; proxy events join the gap-free chain.

#366 MCP consent — attribution binding is secure ✅

• No cross-user misattribution: the callback recovers (corr, task) from engine.Peek(b.subject, b.server) where b.subject is the state-bound subject (PKCE/state/session validation unchanged). The gate is per-(subject, server), so the exchange attributes to the invocation that parked on that subject's gate. Attributing to the first same-subject waiter (when several exist) is deterministic and same-subject.
• Observability-only: the seeded ctx changes only correlation/task/seq — it does not touch what token is minted, for whom, or the resume decision, so it can't cause a wrong token to be exchanged/stored. Good separation across the security boundary.
• Double-emit removal loses no event: POST /mcp/consent drops its emit because Peek guarantees a waiter and the waking gate emits the attributed terminal event (and a resolved for a timeout refusal was genuinely misleading). The loopback callback now emits only on Resolve-finds-no-waiter — the genuine "late grant after timeout" case, marked late: true and honestly unattributed (no live invocation).
• The scope boundary (pooled subject_pool.go connection = shared-across-invocations infra, deferred rather than forced onto one arbitrary invocation) is the right judgment and honestly documented.

Two things I considered and dismissed (recording so they don't resurface)

1. Nested register/evict: not a concern — tasks/send (JSON-RPC + REST) delegates to executeTask, which registers internally, while the registerInvocationSeq defers in the streaming (tasks/sendSubscribe) handlers cover the inline-executing streaming path. A request is either non-streaming or streaming, so the two paths are mutually exclusive — no double-registration, no early-evict window.
2. Single registry mutex: taken per proxy egress event + per request entry/exit, but O(1) map ops under a brief lock — fine at realistic audit volume; sharding/sync.Map would be premature.

Tests cover the registry (Register/Get/Evict/NextSequenceFor, shared-counter, -race, nil-safe), the runner sharing+evicting, and the callback seeding the parked (corr, task) + counter.

Nice design — the SequenceRegistry seam unifying both defects is clean, and keeping attribution observability-only leaves the delegated-consent security model untouched.